-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Add render diagnostic functions for reading from a buffer #22326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add render diagnostic functions for reading from a buffer #22326
Conversation
tychedelia
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not blocking but would be nice to add vec2/3/4. thanks this is great!
| name: Cow<'static, str>, | ||
| is_f32: bool, | ||
| ) { | ||
| let dest_buffer = self.device.create_buffer(&BufferDescriptor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probs not a huge deal since this is debug code but we could probably re-use these allocations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we could reuse them or suballocate from one larger buffer, but I didn't want to deal with the complexity of that... Decided to go the dumb route for now.
Sadly bevy diagnostics only supports a single f64 value :/ |
pcwalton
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please. Would be nice to have i32 support as well but obviously we shouldn't block the PR on that.
|
Actually going to punt on i32, it's rarely used in graphics contexts. |
# Objective - Greatly reduce light leaks near corners of objects (but doesn't fix general light leaks from tiny geometry) ## Solution To prevent light leaks: - When ray_t is smaller than the cache cell size, force the finest LOD cache access. - Make LOD much less aggressive - Make the finest LOD smaller Since this then greatly increases the number of cache cells in the scene, I changed the following to prevent too much of a decrease in performance (this PR is still a hit to performance though): - Randomly skip updating some cells once we have more than 40,000 cells active - Aggressively prune older cache cells Also some misc changes: - Turn world cache query jitter back on (stabilizes glossy reflections) - Split the DI/GI WC sampling steps into separate dispatches (small performance win) - Added a counter of current WC cell count to the example UI (using #22326) Ideally the skipped cells wouldn't be totally random, and we'd have coarser-LOD cells update less frequently, but that would get very complicated as we'd have to track the total amount of cells per LOD in order to average out to `WORLD_CACHE_TARGET_CELL_UPDATES`.
See release note file.
Tested locally on a modified copy of Solari.